《Day 06：從筆記到知識庫，素材的收集與初步整理》 結尾留下一個具體的問題。知識庫雛形份量過大、內容依然龐雜，要如何切成方便查詢的小單位，同時不能切壞程式碼與上下文的完整性。今天要正式回答這個問題，也要在今天為系統地基階段畫下句點。

雛形有了，但還是太大、太雜

想像一個畫面。寫作代理人需要查證某個技術細節時，翻到知識庫裡對應的那一則素材，發現這則素材本身篇幅不小，甚至混雜著好幾種不同主題的說明。Agent 不可能每次查證都把整份原始資料吞下去，這樣做既沒有效率，也違背了知識庫存在的初衷。

今天的任務，就是定義知識庫要被切分成什麼樣的小單位，才方便查詢引用，正式解決「怎麼切」這個問題。

為什麼需要切分？效率與精準度的雙重理由

切分帶來的收益，可以拆成兩個理由來看。

效率理由，Agent 每次查證只需要與當下問題直接相關的內容。如果每次查證都要讀取整份龐大的原始資料，會浪費大量不必要的處理成本，也會讓真正相關的內容被淹沒在大量不相關的文字裡。

精準度理由，一份混雜多種主題的長文件，被整份拿來查證時，Agent 反而更容易在不相關的段落裡誤讀出看似相關但實際上文不對題的內容。切分成聚焦單一主題的小單位，能讓每一次查詢命中的內容更加精準。

切分的目的，是為了讓知識庫真正好用，而不是把知識庫拆得支離破碎，這是今天要解決的核心問題。

正式定案，知識庫切分單元

今天要為知識庫被切分後的最小檢索單位，定下一個正式名稱：知識庫切分單元。

知識庫切分單元的定義是，知識庫雛形被切分後、供 Agent 檢索引用的最小單位，切分依據為保留完整可理解的最小語意單位，而非固定字數或固定行數。這個單位單獨被取出查閱時，不需要額外拼湊其他片段，就能完整理解其中的程式碼行為或論證脈絡。

這個定義一旦定案，即成為全系列的既定錨點，後續任何天數提到切分後的最小檢索單位時，一律使用這個詞。

這個定義聽起來合理，但實際切分時要怎麼判斷多大算完整、多小算太碎，這正是接下來要處理的風險。

切分過細的風險，語意斷裂

不少人可能有過這樣的經驗，在網路上查到一段程式碼片段，卻看不出前面宣告了什麼變數、依賴哪個套件版本，只能拿著這段片段一頭霧水。這種挫折感，正是今天要論證的核心危害，語意斷裂。

語意斷裂是怎麼發生的。如果切分時機械式地按照固定字數或固定行數切割，很可能把一段完整的程式碼範例攔腰切斷，例如函式的定義被切到一個單位，呼叫這個函式的示範被切到另一個單位。Agent 查證時只拿到其中一半，既看不出完整的呼叫方式，也可能誤判這段程式碼本身是不完整或有問題的。

同樣的風險也發生在論證脈絡上。一段技術原理的說明如果依賴前面幾句話鋪陳的前提，被切分後只留下結論性的句子，Agent 查證時會拿到一句脫離脈絡的斷言，卻不知道這句話成立的條件與前提是什麼。

切分過細導致查詢時只拿到片段本身，遺失了理解這段程式碼或論證所必須的上下文，這樣的查證結果比完全不切分、直接讀取整份原始資料更糟，因為它讓查證動作產生一種已經看過依據的虛假安心感，實際上依據本身已經殘缺不全。這與 [[Day 06：從筆記到知識庫，素材的收集與初步整理]] 提過的「看起來有出處但出處不可靠」是同一種風險的不同變形，只是這次的成因換成了切分方式不當，而非素材本身過時或錯誤。

應對原則，以完整語意為準則，而非固定尺寸

應對這個風險的原則是，切分時應該以保留完整可理解的最小語意單位為準則，也就是每一個知識庫切分單元，都必須是單獨拿出來查閱時就能被完整理解的最小範圍，而不是機械式地按照固定字數或固定行數切割。

落實在程式碼上，一段程式碼範例如果包含函式定義與呼叫示範，這兩者如果彼此依賴才能被完整理解，就應該被視為同一個知識庫切分單元，不應該因為湊到某個字數上限就被攔腰切開。落實在論證脈絡上，一段技術原理的說明如果前面的前提是理解後面結論的必要條件，這個前提與結論就應該保留在同一個知識庫切分單元裡，不能只留下結論句。

有一個簡單的判斷測試可以套用，切分完成後，可以自問這個切分單元單獨交給一個完全不知道上下文的人或 Agent 閱讀，對方是否能完整理解其中的程式碼行為或論證邏輯。如果答案是否定的，代表這個單位切得太小，還需要向外納入更多必要的上下文。

知識庫切分單元允許篇幅有大有小，重點從來都是每個單位是否語意完整，不是統一的尺寸。這與 Day 06 初步整理階段「篩選有查證價值的內容」的精神一致，都是把對品質的判斷，放在對數量或格式的機械要求之上。

系統地基階段回顧，四大病灶被回應到什麼程度

今天是系統地基階段的收尾篇章，我們來看看這四天的產出，究竟如何回應 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的四大病灶：注意力稀釋、內容漂移、事實幻覺、零容錯結構。

Section Spec 定義了規劃代理人與寫作代理人之間的交接格式，全域錨點檔案記錄了已定案的結論作為跨天共享的單一事實來源，知識庫收集整理並切分成語意完整的小單位，成為可查證引用的原始依據。這三塊拼圖合起來，對四大病灶的回應程度並不均等。

回應最直接的是事實幻覺。知識庫的存在，讓寫作代理人在交代技術細節時，不必單靠訓練時累積的模糊印象作答，而是有一份經過初步整理、且以語意完整的知識庫切分單元組織起來的可查證依據可以引用。這直接對應事實幻覺病灶完全依賴訓練記憶、沒有查證過時知識點這個根因。

其次是內容漂移。Day 05：系列的單一事實來源，打造全域錨點檔案 定案的全域錨點檔案，讓已經定案的名詞與架構決策不必仰賴任何單一角色的記憶，跨天協作時可以持續查閱同一份權威來源，這直接對應內容漂移病灶長文本或多日累積下風格與深度逐漸偏離初始設定這個根因。

注意力稀釋與零容錯結構這兩項，系統地基階段只有間接貢獻。Day 04：規劃代理人的產出介面，認識 Section Spec 定案的 Section Spec，讓規劃與撰寫的職責被明確拆分並各自產出結構化交接物，間接減少了單一次生成裡宏觀推理與微觀查證被迫混雜切換的情況。知識庫切分成語意完整的小單位，也讓後續若發現某則素材有誤，只需要更新對應的知識庫切分單元，不必牽動整份知識庫重新整理，對零容錯結構有間接的緩解效果。但這兩項病灶真正被完整解決，還要等到規劃代理人與寫作代理人各自的開發階段收尾時才會有更完整的答案。

坦白講，到現在系統地基階段，還沒有真正打造出任何一個會動的 Agent，四大病灶目前被回應的程度，是打好了讓後續 Agent 能夠正確運作的基礎設施，而非病灶已經被徹底根除。

真正的根除，要等到規劃代理人與寫作代理人被實際打造出來，並且依循這些地基工作之後才能驗收。

地基完工，準備動工蓋房子

今天正式定案了知識庫切分單元，它是知識庫雛形被切分後供 Agent 檢索引用的最小單位，切分的準則是保留完整可理解的最小語意單位，而非機械式的固定字數或固定行數切割，這樣才能避免切分過細導致語意斷裂，讓查證結果比不切分更糟。

連同今天以前建立的 Section Spec 與全域錨點檔案，系統地基階段正式完工。這三塊拼圖，是規劃代理人與寫作代理人接下來所有工作共同依賴的基礎設施。

但地基蓋完不等於房子蓋好。接下來終於要開始打造第一個完整的 Agent，也就是規劃代理人本身。這個角色具體要怎麼被設計出來，它的系統提示詞要怎麼寫，才能讓它確實依循今天以前建立的所有地基工作，這個問題還沒有答案，將在 《Day 08：規劃代理人的系統提示詞設計》 正式揭曉。